An application running on a computer system can include a collection of code assemblies (“assemblies”). Generally, an assembly represents a collection of code, such as a collection of components object classes, modules, interfaces, data, metadata, resources, etc. An application can be implemented from a variety of assemblies, and the assemblies may have very different properties. For example, the assemblies can be published by different publishers or retrieved from different Internet locations. An application can include an executable program, utility, applet, service, or top level component. An application can also include a web page as a logical application when the hosting environment is a Web browser.
It is common for applications to persist data on the disk of the computer system (or some other accessible storage medium). One commonly used form of persistent storage is a “cookie”, which is stored in a cookie file on the local hard drive. The use of cookies for persistent storage is limited because access to a cookie is keyed to the remote host and is restricted to only a single cookie per host. In addition, cookies lack flexibility in the type of storage provided so the storage space is not configurable to the needs of the program using it.
One or more components of an application are typically responsible for saving data in a persistent storage location accessible by the computer system. Assemblies that save data in a persistent storage location typically must invent path and files names that are intended to be unique within the storage region. However, there are no guarantees that another application or component, possibly developed by another company, will not use the same path name and file name. For example, an e-commerce application may retain encrypted credit card information for a particular user in a file name “\root\cccrypt.dat” on the hard disk of the computer system. However, because another application may coincidentally use the same path name and file name to persist its data, there is a risk that the second application may corrupt or overwrite the “\root\cccrypt.dat” file of the first application. This risk also compounds security concerns by allowing a possible rogue application to access persistent data of other applications.
Furthermore, some components may be used or shared by multiple applications. For example, a publishing application may use an instance of an image cache class (a persistent storage component) from a shared library (e.g., a .dll file) to persist relevant image data of a publishing document, while a browser application may use another instance of the same image cache class from the same shared library to persist relevant image data from the Web. If the shared image cache component needs to save different data depending on the application or calling component, the component typically requires the application or calling component to pass a presumably unique path name to the shared image cache component. The path name is then used to specify the directory in which to store the persistent data. This approach, however, requires some intelligence by the application or calling component to generate a unique name and still risks data corruption and information leakage if two different applications or calling components provide the same path name and file name to the image cache component. This scenario also risks allowing a possibly rogue application to access persistent data when such access is inappropriate.